System and method for conducting secure payment transaction

ABSTRACT

In a secure electronic payment system, authentication data based on a payment account (e.g., a credit card account) is sent from an authentication server, through a user&#39;s Web browser, to a merchant&#39;s computer. The merchant&#39;s computer sends the authentication data to a computer operated by the issuer of the payment account, either through a payment organization computer or through an acquirer computer operated by the merchant&#39;s acquirer. The issuer&#39;s computer verifies the authorization request message, thereby generating an authorization response message. The authorization response message is forwarded to the merchant&#39;s computer, either through the payment organization computer or through the acquirer computer. If the authorization response message indicates that the verification was successful, the transaction is completed.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part of U.S. patent applicationSer. No. 10/096,271, entitled “System and Method for Conducting SecurePayment Transactions,” filed on Mar. 11, 2002, which is incorporatedherein by reference in its entirety; this application also claimspriority to the following additional application which is incorporatedherein by reference in its entirety: U.S. Provisional Patent ApplicationNo. 60/352,968, entitled “MasterCard UCAF™ and SPA™ ClientlessSolution,” filed on Jan. 30, 2002.

BACKGROUND OF THE INVENTION

On-line shopping offers unprecedented ease and convenience forconsumers, while enabling merchants to reduce costs and obtain newcustomers. However, many consumers have been reluctant to take advantageof these benefits due to fear of theft of sensitive information such ascredit card numbers. Efforts have been made to increase the security ofsuch information. For example, in the secure socket layer (SSL)technique, messages sent between the consumer and the merchant areencrypted, thereby making it more difficult for a third party tointercept and use the information. However, this method does not providethe merchant with any verification of the identity of the consumer.Accordingly, if a third party were to obtain a credit card number byother fraudulent means such as theft of physical credit card, the SSLmethod would not prevent the third party from fraudulently using thestolen information.

Secure Electronic Transaction (SET™) techniques attempt to solve theforegoing problems by using digital certificates to authenticate theconsumer/account holder, the merchant, and the credit card issuer. Eachcertificate is issued by a trusted certificate authority. While SET™ iscurrently the most secure way to handle payments over the Internet, itrequires digital certificates and cryptographic software to be installedand operated on the account holder's computer.

In fact, most prior art secure electronic commerce systems requireconsumers to install special software on their computers. Yet, manyconsumers are reluctant to install such software and, in any case, aspecialized account holder application may not be compatible with a widevariety of account holder access devices—e.g., personal computers,personal digital assistants, and mobile communication devices such asmobile telephones. As a result, it has been difficult for some secureelectronic commerce systems to gain widespread acceptance amongconsumers.

SUMMARY OF THE INVENTION

It is therefore an object of the present invention to provide a paymentsystem which enables a consumer to make on-line purchases withoutcompromising sensitive information such as the consumer's accountnumber.

It is an additional object of the present invention to provide a paymentsystem in which the identity of a consumer is authenticated withoutrequiring the issuance of a large number of digital certificates.

It is still a further object of the present invention to provide apayment system in which information security is maintained and theidentities of on-line consumers are authenticated, without requiringconsumers to download large software files, and without employingcomputationally intensive calculations which might slow down theconsumer's computer.

It is yet another object of the present invention to provide a paymentsystem compatible with a wide variety of different account holder accessdevices.

These and other objects are accomplished by a method and system forconducting an online payment transaction, in which authentication datais sent from an authentication processor (e.g., a computer operated by apayment organization) to a user processor (typically a purchaser'scomputer), then to a merchant's processor, then to an acquirer processoror the payment organization processor, and then to an issuer processor(typically, a computer operated by the issuer of the purchaser'scredit/debit card account or other payment account) for verification.The result of the verification is sent back to the merchant processorthrough the payment organization processor or the acquirer processor,whereupon the merchant processor either denies or completes thetransaction. To generate the authentication data, the user processorsends payment account identification data (e.g., a credit card or debitcard number) to the merchant processor, which sends an account holderparticipation request message to a registration database processor todetermine whether the payment account is listed in a registrationdatabase. If the payment account is listed, the registration databasesends a URL through the merchant processor which passes the URL on tothe user processor. The user processor uses a Web browser to access acredential collection page provided by the payment organization. Theuser processor fills in the credential collection page and sends anauthentication request message to the authentication processor, whichauthenticates the data and, if the authentication is successful,provides the aforementioned authentication data.

BRIEF DESCRIPTION OF THE DRAWINGS

Further objects, features, and advantages of the present invention willbecome apparent from the following detailed description taken inconjunction with the accompanying figures showing illustrativeembodiments of the invention, in which:

FIG. 1 is a block diagram illustrating an exemplary system forconducting a payment transaction in accordance with the presentinvention;

FIG. 2 is a block diagram illustrating an additional exemplary systemfor conducting a payment transaction in accordance with the presentinvention;

FIG. 3 is a flow diagram illustrating an exemplary procedure forconducting a payment transaction in accordance with the presentinvention;

FIG. 4 is a flow diagram illustrating an exemplary authorization paymentprocedure for use in the procedure illustrated in FIG. 3;

FIG. 5 is a flow diagram illustrating an additional exemplaryauthorization procedure for use in the procedure illustrated in FIG. 3;

FIG. 6 is a flow diagram illustrating an exemplary authorization requestmessage verification procedure for use in the authorization proceduresillustrated in FIGS. 4 and 5;

FIG. 7 is a flow diagram illustrating an additional exemplaryauthorization request message verification procedure for use in theauthorization procedures illustrated in FIGS. 4 and 5;

FIG. 8 is a block diagram illustrating an exemplary account holderauthentication value (AAV) in accordance with the present invention;

FIG. 9 is a diagram illustrating an exemplary computer system forperforming the procedures illustrated in FIGS. 3-7; and

FIG. 10 is a block diagram illustrating an exemplary processing sectionfor use in the computer system illustrated in FIG. 9.

Throughout the figures, unless otherwise stated, the same referencenumerals and characters are used to denote like features, elements,components, or portions of the illustrated embodiments.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 illustrates an exemplary system for performing secure paymenttransactions in accordance with the present invention. The systemincludes a user processor 102 operated by user and running user software(typically, a Web browser), a merchant processor 104 operated by amerchant selling goods and/or services, an acquirer processor 106operated by an acquirer—typically the merchant's acquiring bank—and anissuer processor 108 operated by an issuer—typically a financialinstitution such as a bank—that has issued a payment account being usedto conduct a transaction with the merchant. The system further includesa registration database processor 110 and an authentication processor114 which can be separate computers, but which are more typicallyimplemented as portions of the software of a payment organizationprocessor 112. The payment organization processor 112 is operated by apayment organization such as the MasterCard® payment organization and ispreferably a server computer connected to a network 126 such as theInternet. The user processor 102 typically is, or is included in, anaccess device such as, for example, a computer, a personal digitalassistant (PDA), or a mobile telephone. Preferably, the user processor102 runs a Web browser which supports name-based addressing of Web pagefields, in order to enable identification of hidden and visible fieldsusing names which are uniform for multiple merchants and accountholders. The price(s) of the good(s) and/or service(s) being purchasedare charged to a payment account of an account holder. The paymentaccount is typically a credit card account, a debit card account, and/orany other type of payment card account. The account can, but need notbe, associated with a physical card. For example, the payment accountcan be associated with a virtual card which can be stored electronicallyin the user processor 102. The purchaser can, but need not be, theaccount holder. The system uses authentication data 164 whicheffectively travels from the authentication processor 114 to the userprocessor 102, then to the merchant processor 104, then to the acquirerprocessor 106, and then to the issuer processor 108 for verification.The data 170 ultimately received by the issuer processor 108 shouldmatch the authentication data 164 originally generated by theauthentication processor 114, provided that no improper operations havebeen performed upon the data 164 during its trip through the system. Theauthentication processor 114 and the issuer processor 108 share allnecessary information regarding the authentication data 164, therebyallowing the issuer processor 108 to verify the data 170 upon receipt.The issuer processor 108 can thus authenticate the identity of theaccount holder and verify the authenticity of the transaction based uponthe authentication data 164 sent by the authentication processor 114 andthe data 170 received by the issuer processor 108. The paymentorganization typically operates not only the payment organizationprocessor 112, but also the registration database processor 110 and theauthentication processor 114. However, in some cases, the authenticationprocessor 114 is operated by the issuer.

FIG. 8 illustrates an example of a data structure 802—referred to hereinas an Account Holder Authentication Value (AAV)—which can be used as theauthentication data 164 illustrated in FIG. 1. The AAV 802 comprises 24bytes of binary data representing 32 Base-64-encoded characters. Thefirst 14 bytes 808 can generally be referred to as system data, andinclude a control byte 804 and other system data 806. The remaining 10bytes 810 of data are defined by the issuer. The control byte 804provides information regarding the type of authorization beingperformed. For example, the control byte 804 has a hexadecimal value of“82” for an initial authorization or pre-authorization of accountholder, and a value of “02” for subsequent authorizations of the accountholder. Additional authentication approaches are assigned their owncontrol byte values. For example, a biometrics-based authenticationprocedure would have its own value for the control byte 804. Table Idescribes the various portions of the AAV 802. TABLE I # Data ElementLength Data Description 1 Control Byte 804  1 Byte Value = hexadecimal“82” indicates initial AAV Value = hexadecimal “02” indicates subsequentAAV 2 Sale Amount  2 Bytes Consists of the left-most 4 decimal digits ofthe 12-digit sale amount with up to eight leading zeroes deleted. Forexample if the 12-digit transaction amount presented by the merchantconsists of 000008765432, the four digits are 8765. 3 Sale Amount  4Bits The above process for filling in the Sale Amount data TruncationField can exclude some of the right-most digits of the original 12-digitamount. This field indicates how many such digits are so excluded. Forexample, if the 12-digit transaction amount consists of 000008765432, sothat the four selected digits are 8765, then the three right-most digitsof “432” would be excluded. In this case the Truncation Field wouldcontain the value “3”. 4 Transaction 12 Bits Consists of the 3 decimaldigit ISO 4217 currency Currency Code code as included by the merchantin its payment page through a hidden field. Convert the three decimaldigit Currency Code to binary, right-justify the resulting 10 bits in a12 bit field, padded to the left with binary “00”. 5 SHA-1 hash of  7Bytes Consists of the left-most 7 bytes of the SHA-1 hash Merchant Nameof the Merchant Name included by the merchant in the hidden field on itspayment page. Merchant Name can first be edited as discussed below. 6Merchant Transaction  2 Bytes A number generated by the merchant. Ifthis hidden Stamp (MTS) field has a hexadecimal value of “00 00,” thisindicates that a random number has not been generated. 7 Issuer-definedData 10 Bytes Contains issuer-generated account holder 810authentication data. Preferably these data uniquely relate thetransaction to the account holder.

As is indicated in Table I, data element no. 1, a/k/a the control byte804, is set to hexadecimal “82” for all AAVs associated with initialauthorizations, including pre-authorizations. Elements 2-6 are thesystem data 806, which are transaction-specific details provided by themerchant's Web site. Element number 7 comprises the issuer-defined data810. This element contains data that links the account holder to theparticular transaction.

The system data 806 and the issuer-defined data 810 of the AAV 802 aregenerated and linked to a particular payment account by theauthentication processor 114. Upon receiving a request 162 forauthentication of an account holder's identity, the authenticationprocessor 114 generates the system data 806 and the issuer-defined data810 in binary format. The two sets of data 806 and 810, along with thecontrol byte 804, are combined to form a 24-byte binary version of the802. Base 64 encoding of the 24-byte binary version produces a32-character, Base 64 version of the AAV 802.

The system data 806 are created based on the control byte 804 and oninformation supplied from the merchant's confirmation page. The data 806are generated using the following procedure:

-   -   1. A control byte 804 is created for the AAV 802. The control        byte 804 can be, for example, a binary-coded decimal        representation of the hexadecimal value “82.”    -   2. The Sale Amount is created by the following steps:        -   a. Up to 8 leading zeros are deleted from the Sale Amount        -   b. The first four remaining Sale Amount digits are placed in            the Sale Amount field as 4 binary coded digits.    -   3. The number of right-most digits of the Sale Amount that were        excluded in Step 2b is determined. This number, which is a        single, binary-coded decimal digit, is placed in the Sale Amount        Truncation Field.    -   4. The 3-digit decimal Currency Code is converted to binary, and        the resulting 10 bits are right-justified in a 12 bit field and        padded to the left with binary “00.”    -   5. The Merchant Name, which is represented by a set of        hexadecimal Unicode control values, is edited using the        following rules, but only if the name is expressed as a Latin-1        character set. All other character sets require no editing.        -   a. All Latin-1 control characters are deleted. These are            Unicode characters in the hexadecimal range 0000 through            001F, and 007F through 009F.        -   b. With the exception of “&” (hexadecimal 0026), “@”            (hexadecimal 0040), “¼” (hexadecimal 00BC), “½” (hexadecimal            008D), and “¾” (hexadecimal 00BE), any remaining Latin-1            non-alphanumeric character is replaced with a space            character (hexadecimal 0020). The Unicode non-control and            non-alphanumeric characters are those in the sets 0021            through 002F, 003A through 0040, 005B through 0060, 007B            through 007E, 00A0 through 00BF, 00D7, and 00F7.        -   c. Any character in the General Punctuation character set            (2000 through 206F) is replaced with a space character            (0020).        -   d. Any Latin-1 numeric digits (0030) through (0039) beyond            the third such digit are deleted so as to include only the            first three numeric digits in the Merchant Name.        -   e. After completion of the prior steps (a) through (d), all            consecutive space characters (0020) are replaced with a            single space character (0020).        -   f. After completion of all prior steps, all leading and            trailing space characters are deleted.    -   6. An SHA-1 hash of the edited (or unedited) Merchant Name is        created and used to fill data element no. 5 listed in Table I.    -   7. The MTS from the merchant's payment screen is inserted into        the MTS field as a binary coded decimal.

The resulting 14-byte binary value is the system data 806 which will becombined with the issuer-defined data 810 and then Base 64 encoded tocreate the AAV 802.

The procedure used to generate the issuer-defined data 810 depends onthe approach that will ultimately be used to verify the AAV 802. Forexample, in a cryptographic approach, the issuer-defined data element810 is generated by encrypting a number, text string, or other dataselected by the issuer. For example, the data to be encrypted can be aconcatenation of the merchant name, the transaction amount, the date,and the account number of the account being used to make the purchase.The data is encrypted using a secret key—discussed in further detailbelow—to generate a cryptographic Message Authentication Code (MAC).Preferably, the MAC is generated by an ISO-approved encryptionalgorithm. The MAC is incorporated into the issuer-defined data 810which is combined with the system data element 804 and 806 to form theAAV 802. During authorization, the issuer processor 108cryptographically verifies the issuer-defined data element 810 to verifyits authenticity. The cryptographic approach is particularly beneficialfor systems in which the AAV 802 is created by one facility and verifiedby a different facility, wherein the two facilities are not in real-timecommunication. For the cryptographic approach, the issuer-defined data810 in the AAV 802 includes the data elements described in Table II.TABLE II Data Type Description AAV Format Indicates the format of theissuer-defined data 810. Number Authentication If this issuer usesmultiple authentication processors, Processor this is an indication ofwhich processor produced this Identifier AAV. Key Identification Used toidentify the cryptographic key used by this Data authenticationprocessor to generate the AAV MAC. Transaction A unique number assignedto this AAV by this Sequence authentication processor. It should notrepeat during Number the longest expected life of any transaction.Message A MAC generated using the above-identified key by Authenticationthe above-identified authentication processor, and Code (MAC) based onthe transaction's account number and on the entire AAV up to the MACfield. It must use an ISO- approved MAC algorithm.

Since the issuer-defined data 810 is limited to 10 binary bytes, it maybe sufficient to include only a portion of each of the above dataelements. Preferably, the data 810 include four bytes of the MAC, fourbytes of the Transaction Sequence Number, one byte of the KeyIdentification Data, and one byte total from the combination of the AAVFormat Indicator and the Authentication Processor Identifier.

The MAC serves as a cryptographic check to detect fraudulent alteration.Both the authentication processor 114 generating the MAC and the issuerprocessor 108 used to verify the transaction have access to the secretcryptographic key used to generate the MAC.

The authentication processor 114 performs the following steps for eachtransaction:

-   -   8. The following AAV data elements are created: AAV Format        Number, Authentication Processor Identifier and Key        Identification Data.    -   9. The Transaction Sequence Number used in the previous AAV is        incremented by a predetermined amount selected by the issuer.        One or more of the right-most bits of the incremented value are        used as the AAV Transaction Sequence Number data element.    -   10. Using the key indicated by Key Identification Data, a MAC is        created by concatenating and encrypting the following data: (1)        the account number provided to the merchant, (2) the entire AAV        excluding the MAC sub-field itself, and (3) any other        issuer-selected data. The left-most portion of the        cryptographically computed MAC is issued as the AAV MAC data        element.

In the cryptographic approach, the issuer processor 108 determines thesecret cryptographic key used by the authentication processor 114 togenerate the MAC. Preferably, the two processors 114 and 108 share asecret, cryptographic Key-Generation Key from which many (hundreds,thousands, or even millions) of MAC-generation keys can be derived. TheKey-Generation Key can be used for years, whereas the MAC-Generation Keyis preferably changed relatively frequently, depending upon therequirements of the MAC-generation algorithm and the issuer'skey-management policy. In any case, however, the Key-Generation Keyshould be changed if there is any suspicion that it has beencompromised.

The shared Key-Generation Key can, for example, be created by the issuerprocessor 108 and conveyed to the authentication processor 114 as one ormore key components, using multiple control (preferably triple control)and split knowledge. The generation and distribution of cryptographickeys should conform to ISO security standards. Similarly, the mechanismby which a MAC-Generation Key is derived from a Key-Generation Keyshould also conform to ISO security standards. Furthermore, anycryptographic key stored within a storage medium connected to anauthentication processor 114 or to an issuer processor 108 preferablyresides solely within physically secure hardware that protects the keyagainst physical compromise in accordance with ISO standards.

If an issuer processor 108 receives AAVs from more than oneauthentication processor, then any cryptographic key that the issuerprocessor 108 shares with one authentication processor should not berelated to any key it shares with another authentication processor.

The following is an example of cryptographic generation of an AAV for aninitial transaction:

Initial Authorization Transaction Example Data:

-   Control Byte Value: 82-   Sale Amount: $87654.32-   Currency Code: 840-   Merchant Name (Unicode representation of SPA Merchant, Inc.):-   0053 0050 0041 0020 004D 0065 0072 0063 0068 0061 006E 0074 002C    0020 0049 006E 0063 002E-   MTS: FOB-   Issuer-defined data: 55390900400486471234-   SHA-1 hash of merchant name (after editing as described above)=31 98    BE 30 1F BD 74OF E2 AD 7E D2 ED 82 9E 69 06 EC E3 6F    Would Result in 24 Binary Byte Source:-   82 87 65 38 40 31 98 BE 30 1F BD 74 F0 AB 55 39 09 00 40 04 86 47 12    34    Converts to 32 Character Base 64 Encoded String:-   godIOEAxmL4wH7108KtVOQkAQASHRxI0

The details for this example are as follows: Map:AAAAAAAABBBBBBBBBBBBBBBBCCCCDDDDDDDDDDDD Source:   0   2   8   7   6   5   3   8   4   0 Binary:1000001010000111011001010011100001000000 6-Bit: word:    00    40    29    37    14    04 Base64:    A     0     d     1     O     E Map:EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEFFFFFFFFFFFFFFFFSource:   3   1   9   8   B   E   3   0   1   F   B   D   7   4   F   0   A   BBinary:0011000110011000101111100011000000011111101111010111010011110000101010116-Bit: word:00    49    38    11    56    48    07    59    53    52    60    10Base64: A     x     m     L     4     w     H     7     1     0     8     K Map: GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG Source:   5   5   3   9   0   9   0   0   4   0 Binary:0101010100111001000010010000000001000000 6-Bit: word:45    21    14    16    36    00    16 Base64:t     V     0     0     k     A     Q Map:GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG Source:   0   4   8   6   4   7   1   2   3   4 Binary:0000010010000110010001110001001000110100 6-Bit: word:00    18    07    17    49    08    52 Base64:A     S     H     R     x     I     0Result:24 byteSource: 82 87 65 38 40 31 98 BE 30 IF BD 74 FO AB 55 39 09 00 4004 86 47 12 34Converts to 32 character Base 64 encoded string:godIOEAxmL4wH71OBKtVOQkAQASHRxIO

The following is an example of cryptographic generation of an AAV for asubsequent transaction:

Subsequent Transaction Example Date:

-   Control Byte Value: 82-   Sale Amount: $87654.32-   Currency Code: 840-   Merchant Name (Unicode representation of SPA Merchant, Inc.):-   0053 0050 0041 0020 004D 0065 0072 0063 0068 0061 006E 0074 002C    0020 0049 006E 0063 002E-   MTS: FOAB-   Issuer-defined data: 55390900400486471234-   SHA-1 hash of merchant name (after editing as described above)=31 98    BE 30 1F BD 740F E2 AD 7E D2 ED 82 9E 69 06 EC E3 6F    Would Result in 24 binary byte Source: 02 87 65 38 40 31 98 BE 30 1F    BD 74 F0 AB 55 39 09 00 40 04 86 47 12 34    Converts to 32 Character Base 64 Encoded String:-   AodIOEAxmL4wH7108KtVOQkAQASHRO0

The details for this example are as follows: Map:AAAAAAABBBBBBBBBBBBBBBBBCCCCDDDDDDDDDDDD Source:   8   2   8   7   6   5   3   8   4   0 Binary:1000001010000111011001010011100001000000 6-Bit: word:    32    40    29    37    14    04 Base64:    g     o     d     1     0     E Map:EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEFFFFFFFFFFFFFFFFSource:   3   1   9   8   B   E   3   0   1   F   B   D   7   4   F   0   A   BBinary:0011000110011000101111100011000000011111101111010111010011110000101010116-Bit: word:00    49    38    11    56    48    07    59    53    52    60     10Base64: A     x     m     L     4     w     H     7     1     0     8Map: GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG Source:   5   5   3   9   0   9   0   0   4   0 Binary:0101010100111001000010010000000001000000 6-Bit: word:45    21    14    16    36    00    16 Base64:t     V     0     0     k     A     0 Map:GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG Source:   0   4   8   6   4   7   1   2   3   4 Binary:0000010010000110010001110001001000110100 6-Bit: word:00    18    07    17    49    08    52 Base64:A     S     H     R     x     I     0Result:24byteSource: 82 87 65 38 40 31 98 BE 30 IF BD 74 FO AB 55 39 09 00 4004 86 47 12 34Converts to 32 character Base 64 encoded string:godIOEAxrnL4wH7IO8KtVOQkAQASKRxIOMap Legend:A - Control Byte value represented as Binary Coded Decimal (BCD)B - Sale Amount - 4 most significant digits represented as BCDC - Sale Amount Truncation Field - single digit represented as BCDD - Currency Code - 3 digits represented as binaryE - SHA-1 hash of Merchant Name ú First 7 bytes of SHA-1 hash valueF - MTS - 2 byte valueG - Issuer-defined Data - 10 bytes of issuer-defined data represented asBCD

A comparative approach is preferred for systems in which the AAVcreation and verification facilities—the authentication processor 114and the issuer processor 108, respectively—are in real-timecommunication with each other—e.g., via a common data storage system. Inthe comparative approach, the issuer-defined data 810 are generatedusing a random number or any other algorithm selected by the issuer. Theresulting value 810 is combined with the system data 806 to form the AAV802. The AAV 802 is then saved to a common database that is used by theissuer processor 108 to verify transaction authenticity. Duringverification, the issuer processor 108 verifies the authenticity of atransaction by comparing the AAV received in the authorization request170 to the AAV stored in the database. The AAV for the comparativeapproach is generated and stored according to the following procedure:

-   -   11. Generate the issuer-defined data 810 in accordance with the        issuer's definition—e.g., by a random number generator.    -   12. The issuer-defined data 810 are stored in a database linking        them at least to a particular Account Number.    -   13. The merchant hidden field data are stored in a database        linking them at least to the issuer-defined data 810.    -   14. The database is made available to the issuer processor 108.    -   15. The issuer-defined data component 810 is combined with the        system data component 808 to form a 24-byte binary value. The        24-byte binary value is Base 64 encoded to generate the 32        character 702.

FIG. 3 illustrates an exemplary procedure for operating the paymenttransaction system illustrated in FIG. 1 using authentication data 164which includes the AAV 802 described above. In the illustratedprocedure, the shopper (who, in many cases, is the account holder or aperson related to or representing the account holder) browses thevarious pages of a Web site available from the merchant processor 104(step 302). The shopper finds and selects goods and/or services that(s)he would like to purchase from the merchant (step 304). Once thegoods and/or services have been selected, the shopper initiates themerchant's checkout procedure (step 306). For example, in the commonlyused “shopping cart” method, the shopper selects goods and/or servicesto be placed in a virtual shopping cart—i.e., a list of items that theshopper tentatively plans to purchase. Once the list of items iscompleted to the satisfaction of the shopper, the shopper initiatescheckout by clicking on a visible “checkout” button on the merchant'sWeb page, at which point the checkout procedure begins with respect tothe items in the shopping cart. Another method employs a single-clickcheckout procedure in which the merchant processor 104 stores accountholder information and then uses the information for multipletransactions. The stored information is provided by the account holderduring a registration process and can include the account holder'sbilling and shipping addresses, e-mail address, account number, andaccount expiration date. The account holder can then immediatelyinitiate checkout with respect to an item (step 306) by clicking on avisible “purchase” button associate with the item.

Once the checkout phase has been initiated (Step 306), if the accountholder has not registered for single-click shopping (step 308), themerchant processor 104 provides the user processor 102 with additionalWeb page data through a portion 122 of the network 126 (step 318). Thenetwork 126 is typically the Internet. The Web page data is used todisplay a “checkout” Web page (a/k/a an “order confirmation” Web page)on the account holder's computer screen. The account holder and/or theuser processor 102 provide(s) billing address, shipping address and/orpayment account details to the merchant processor 104 by entering someor all of this information into fields on the confirmation page (step320). The billing and shipping address information can be enteredmanually by the account holder, filled in automatically by the userprocessor 102, or filled in automatically by the merchant processor 104based on information stored in the merchant processor 104 and associatedwith the particular account holder. To confirm the order, the accountholder clicks a visible “submit” button on the confirmation page (step322). The purchase is authorized using an authorization procedure 324which utilizes the aforementioned technique of sending authenticationdata 164 from the authentication processor 114 to the user processor102, to the merchant processor 104, to the acquirer processor 106, andthen to the issuer processor 108 for verification. Examples of theauthorization procedure 324 are described in further detail below withreference to FIGS. 4 and 5.

If, in step 308, it is determined that the account holder is registeredfor single-click shopping, the user processor 102 fills a “single-click”indicator field on the merchant's Web page with a code (e.g., “01”)notifying the merchant processor 104 that the account holder isregistered for single-click shopping (step 310). The Web page with thefilled single-click indicator field is submitted to the merchantprocessor 104 (step 312). The merchant processor 104 sends confirmationpage data to the user processor 102 (step 314). However, the purchaseronly sees a page or window with a simple message such as, e.g., “OrderBeing Processed.” While this message is being displayed, the userprocessor 102 automatically fills various hidden fields on theconfirmation page with the account holder's address information andaccount number (step 316). The aforementioned authorization procedure324 is then performed.

Regardless of whether the transaction is a single-click purchase, ifauthorization is granted by authorization procedure 324 (step 326), thegood and/or services are shipped, delivered, or otherwise provided tothe purchaser (step 332). Any conventional clearing and settlementprocedure can be used to clear and settle payment between the paymentaccount issuer and the merchant's acquirer (step 334). On the otherhand, if authorization has been denied (step 326), then the accountholder is notified of the denial (step 328), and the transaction isterminated (step 330).

An example of a procedure 324 for using the authentication data 164 toauthorize a transaction is illustrated in FIG. 4. The user processor 102sends payment account identification 152 data such as the account numberto the merchant processor 104 (step 402). The data 152 is sent through aportion 122 of a network 126 which is typically the Internet. Thepayment account identification data 152 typically includes the accountnumber associated with the payment account. The merchant processor 104sends an account holder participation request message 154 to theregistration database processor 110 (step 404). The registrationdatabase processor 110 includes, or otherwise has access to, aregistration database which is preferably stored on a computer readablemedium 116 within or connected to the registration database processor110. As is discussed above, the registration database processor 110 canbe incorporated into a payment organization processor 112 which furtherincludes an authentication processor 114. The account holderparticipation request message 154 comprises either: (a) the paymentaccount identification data 152 sent from the user processor 102 to themerchant processor 104, or (b) data derived from the payment accountidentification data 152. The account holder participation requestmessage 154 is preferably sent through a portion 132 of the network 126.The registration database processor 110 processes the account holderparticipation request message 154 to determine whether the paymentaccount indicated by the message 154 is listed in the registrationdatabase (step 406). If the indicated payment account is not listed inthe database (step 408), the registration database processor 110 sendsan account holder participation response message 156 to the merchantprocessor 104 notifying the merchant processor 104 of this result (step409). The merchant processor 104 then processes the transaction using aconventional procedure (step 410). If, however, the payment account islisted in the registration database (step 408), the account holderparticipation response message 156 sent from the registration databaseprocessor 110 to the merchant processor 104 indicates that the paymentaccount is listed, and includes first resource locator data (e.g., aURL) (step 412). The first resource locator data indicates a networkaddress/location of a credential collection page. The credentialcollection page is preferably located within the payment organizationprocessor 112. The merchant processor 104 sends second resource locatordata 158 to the user processor 102 via the merchant Web page (step 414).The second resource locator data 158 are identical to or derived fromthe first resource locator data. The user processor 102 uses the secondresource locator data 158 (e.g., the URL of the credential collectionpage) to access the credential collection page through the network 126(e.g., through network portion 124) by receiving credential collectiondata 160 representing the credential collection page (step 416). Thecredential collection page is typically configured as a form which isfilled in by the user processor 102 and then submitted as anauthentication request message 162 sent from the user processor 102 tothe authentication processor 114 (step 418). The credential informationprovided by the user processor 102 typically includes a user name, apassword, an account number, and transaction details such as themerchant name and sale amount. The authentication processor 114authenticates the authentication request message 162 (step 420). If theauthentication is not successful (step 422), the authenticationprocessor 114 sends to the user processor 102 an authentication responsemessage 164 notifying the user processor 102 of the rejection (step424). If, however, the authentication is successful (step 422), theauthentication response message 164 sent from the authenticationprocessor 114 to the user processor 102 indicates that theauthentication was successful and includes authentication data such asthe AAV described above (step 426). The user processor 102 then sends tothe merchant processor 104 data 166 comprising or derived from theauthentication response message 164 (step 428).

A first authorization request message 168 is sent from the merchantprocessor 104 to the acquirer processor 106, preferably through anetwork or network portion 128 (step 430). The first authorizationrequest message 168 preferably includes either the AAV received by themerchant processor 104 in step 428 or a MAC extracted from this AAV. Theacquirer processor 106 sends a second authorization request message 170to the issuer processor 108, preferably through a network or networkportion 130 (step 432). The second authorization request message 170includes the aforementioned AAV or MAC. The issuer processor 108verifies the MAC (step 434) to generate a first authorization responsemessage 172 which is sent to the acquirer processor 106 throughnetwork/network portion 130 (step 436). The first authorization responsemessage 172 indicates whether the verifying step (step 434) wassuccessful. The acquirer processor 106 sends to the merchant processor104—through network/network portion 128—a second authorization responsemessage 174 comprising, or derived from, the first authorizationresponse message 172 (step 438). As is discussed above with respect tothe procedure illustrated in FIG. 3, the merchant processor 104 providesthe requested goods and/or services (step 332) or notifies the accountholder that authorization was denied (step 328), depending upon whetherthe verification step (step 434) was successful (step 326), as indicatedby the second authorization response message 174.

The merchant processor 104 preferably captures and retains the AAV forfuture use in linking the account holder to a specific transaction. Thedata can also be used for performing subsequent authorizations ofsplit-shipments, and may be of value to the merchant 404 duringexception processing.

The merchant processor 104 ensures that it has not received a fraudulentAAV 802 by confirming that the most significant bit of the control byte804 is a “1.” This can be done by verifying that the left-most characterof the Base 64 encoded AAV 802 is a lower case “g.”

The Merchant Name is verified by confirming that the hash of theMerchant Name, as included in the AAV, exactly matches the hash of theMerchant Name that was included in one of the hidden fields. Toaccomplish this, the merchant processor 104 verifies that characters 7through 16 of the Base 64 encoded AAV 802 exactly match a pre-computedvalue. This pre-computed value can be obtained by performing the SHA-1hash process of the Merchant Name.

For example an AAV may be:

-   -   god1OEAxmL4wH7108KtVOQkAQASHRx10

The merchant verification process would parse out characters 7-16:

-   -   AxmL4wH710

The merchant processor 104 compares this value to the known SHA-1 hashof the Merchant Name. If the value is not successfully validated, themerchant processor 104 declines the transaction.

Optionally, the merchant processor 104 can also validate the AAV saleamount based on the sale amount presented in one of the hidden fields.The merchant processor 104 converts the Base 64 encoded AAV 802 to its24 binary byte source and identifies the Sale Amount, Sale AmountTruncation Field and Transaction Currency Code. The merchant processor104 validates the Sale Amount, Sale Amount Truncation Field andTransaction Currency Code in accordance with the data descriptions inTable I and the Sale Amount and Currency Code presented via hiddenfields. If the values are not successfully validated, then the merchantprocessor 104 declines the transaction.

Optionally, the merchant processor 104 can also validate the MTScontained in the AAV 802. When validating the MTS, the merchantprocessor 104 identifies the MTS component of the AAV 802 and comparesit to the MTS presented in the order confirmation page hidden field. Ifthe value is not successfully validated, the merchant processor 104declines the transaction, because the AAV 802 is likely to befraudulent.

The authorization request messages 168 and 170 preferably include atleast the following data elements:

-   -   Account holder's Payment Account Number supplied to the merchant    -   Merchant Name    -   Currency Code    -   Sale Amount    -   Merchant Transaction Stamp (default value is set to hexadecimal        “00 00” by the merchant processor 104 if this element is not        being used)

Optionally, the following data elements can also be included:

-   -   Card Acceptor City    -   Card Acceptor State/Country Because the authorization request        messages 168 and 170 contain sensitive, transaction-specific        data and may be transmitted over a public network such as the        Internet, the authorization request messages 168 and 170 are        preferably protected using a secure encryption method—e.g.,        128-bit SSL or equivalent—in order to prevent the data from        being compromised.

FIG. 6 illustrates an exemplary procedure 434 for use by an issuerprocessor 108 processing an authorization request message 170 togenerate an authorization response message 172 such as is discussedabove with respect to FIGS. 1 and 4. The exemplary procedure 434illustrated in FIG. 6 employs a cryptographic verification approachsuitable for use with the cryptographically generated AAV 802 describedabove. In the illustrated procedure 434, the following steps areperformed for each authorization request message 170 received by theissuer processor 108:

-   -   16. The AAV is extracted from the authorization request message,        Base 64 decoded, and interpreted based on the indicated data        format (step 610).    -   17. Using the AAV's Key Identification Data, its Authentication        Processor Indicator, and its Transaction Sequence Number, the        issuer processor 108 determines the cryptographic key to be used        for MAC verification (step 612).    -   18. Using the appropriate MAC algorithm, the processor 108        attempts to verify the MAC within the AAV 802 (step 614). If the        MAC is not successfully verified (step 616), the transaction is        declined (step 618), because the AAV 802 is not valid and the        transaction is therefore assumed to be fraudulent.    -   19. If the Control Byte of the AAV indicates that this is an        initial authorization request (step 620):        -   a. The processor 108 checks whether the same Transaction            Sequence Number (from the authentication processor 114) and            Sale Amount have already occurred in a previous initial            authorization that was received more than “n” seconds ago            (where “n” is to be specified by the issuer, and typically            equals 60) (step 626). The optional delay of, e.g., 60            seconds is to allow for the automatic retransmission of an            authorization request message if the corresponding            authorization response message has been lost.        -   b. If the Transaction Sequence Number has already occurred            in a previous authorization-request message that was            received more than “n” seconds ago (step 626), then the            transaction is declined (step 628); this Transaction            Sequence Number from this authentication processor 114 is a            “detected duplicate.” The attempted transaction involves a            fraudulent replay of a previously valid AAV.        -   c. If the Transaction Sequence Number has not already            occurred (step 626), the AAV's Transaction Sequence Number            is identified as “used” for future transactions (step 632).        -   d. Optionally, after verifying the AAV 802 in this initial            authorization request, the issuer 406 can check the            registration status of the account holder and automatically            register the account holder if the account holder is not            already registered (step 634).        -   e. The AAV is thus confirmed to be valid, and the            transaction is therefore considered successfully verified            (step 630). An indication of successful verification is            included in the first authorization response message 172.    -   20. If the AAV's Control Byte 804 indicates that this is a        subsequent authorization request (step 620), and if the AAV's        Transaction Sequence Number is a “detected duplicate” for the        authentication processor 114 being used (step 622), then the        transaction is declined (step 624). This is a        merchant-originated resubmission of an already replayed SPA        transaction.    -   21. On the other hand, if the TSN is not a detected duplicate        (step 622), then the AAV is valid, and the transaction is        therefore considered successfully verified (step 630). An        indication of successful verification is therefore included in        the first authorization response message 172.

The issuer processor 108 preferably maintains a record of every accountnumber that has been registered for performing AAV-based authentication.In addition, the issuer processor 108 stores the Key-Generation Key (orkeys) that it shares with each authentication processor 114. The issuerprocessor 108 also stores records indicating which AAVs it has alreadyreceived, in order to detect fraudulent replays of account numbers andtheir respective associated AAVs.

AAV verification can also be performed using a comparative approach. Forexample, in the verification procedure 434 illustrated in FIG. 7, theissuer processor 108 performs the following steps for each authorizationrequest message 170:

-   -   1. The issuer processor 108 extracts the AAV from the        authorization request message 170 (step 706).    -   2. The AAV 802 of the authorization request message 170 is Base        64 decoded (step 708).    -   3. If the Control byte of the AAV indicates that this is an        initial authorization request (step 710), the following AAV        procedure is performed based on a comparison of AAV transaction        information stored in the issuer's database with transaction        data contained in the authorization request message 170:        -   a. The issuer processor 108 verifies that the AAV received            in the authorization request message 170 matches an entry in            the issuer's database (step 712). If there is no matching            entry (step 712), the transaction is declined (step 714).        -   b. If the AAV received is determined to be valid based on a            positive match (step 712), the issuer processor 108 verifies            that the issuer-defined data 810 have not been received in a            prior transaction. If the issuer-defined data 810 have been            received in a prior transaction at any time—or, optionally,            more than “n” seconds ago (where “n” typically equals            60)—(step 716), then the transaction is declined and the AAV            802 is labeled as a detected duplicate (step 718).        -   c. If the issuer-defined data element has not been            previously received (step 716) then the issuer-defined data            802 are labeled as “used” (step 720), and additional            validation of the issuer-defined data 810 is performed (step            722).        -   d. The additional data validation can include comparing data            captured from the merchant hidden fields with data contained            in the authorization request message 170 (step 722). This            allows the issuer processor 108 to validate additional            fields such as the Account Number and the Merchant Name. If            the data are successfully validated (step 722), then the            verification of the AAV 802 is considered successful (step            726). An indication of successful verification is therefore            included in the authorization response message 172. If the            data do not match (step 722), then the transaction is            declined (step 724).    -   4. If, in step 710, the Control byte of the AAV indicates that        this is a subsequent authorization request, the following steps        are performed:        -   a. If the issuer-defined data 810 are a “Suspected            Duplicate” data set (step 728), the processor 108 declines            the transaction (step 730).        -   b. If the issuer-defined data 810 were received in an            initial authorization and are not a “Suspected Duplicate”            data set (step 728), then the processor 108 performs            additional validation checks by comparing data captured from            the merchant hidden fields with data contained in the            authorization request message 170 (step 722). This allows            the issuer 406 to validate the Account Number and Merchant            Name. If the data match (step 722), then the verification is            considered successful (step 726), and an indication of            successful verification is therefore included in the            authorization response message 172. Otherwise, the            transaction is declined (step 724).

Optionally, the payment organization processor 112 can perform theverification procedure 434 on behalf of the issuer processor 108, inwhich case the second authorization request message 170 and the firstauthorization response message 172 are sent to and from the paymentorganization processor 112 rather than the issuer processor 108. Inother words, the payment organization processor 112 can “stand in” forthe issuer processor 108. Such “stand-in processing” can be especiallybeneficial if the issuer processor 108 is temporarily unavailable.

In any case, regardless of whether the verification procedure 434 hasbeen performed by the issuer processor 108 or the payment organizationprocessor 112, if the authorization response message 174 received by themerchant processor 104 indicates approval of the transaction (step 326of FIG. 3), the merchant processor 104 preferably presents an HTML-basedreceipt page to the account holder in order to confirm completion of thetransaction. This page preferably contains a reference number for usewith customer inquiries. In addition, the receipt page hosts a hiddentransaction identification field which is not visible to the accountholder but which can be read by the user processor 102 for the purposeof identifying completed transactions. The goods are then shipped and/orthe services are provided (step 332). Any conventional clearing andsettlement procedure can then be used to clear and settle the paymentbetween the issuer and the acquirer (step 334).

FIG. 2 illustrates an additional system for performing secure paymenttransactions in accordance with the present invention. Similarly to thesystem illustrated in FIG. 1, the system illustrated in FIG. 2 includesa user processor 102, a merchant processor 104, and an issuer processor108. The system illustrated in FIG. 2 also includes a registrationdatabase processor 110 and an authentication processor 114, both ofwhich are typically implemented as part of the software of a paymentorganization processor 112. However, the system illustrated in FIG. 2typically does not include an acquirer processor 106. The systemillustrated in FIG. 2 uses authentication data 164 which effectivelytravels from the authentication processor 114 to the user processor 102,then to the merchant processor 104, then to the payment organizationprocessor 112, and then to the issuer processor 108 for verification.

Like the system illustrated in FIG. 1, the system illustrated in FIG. 2can be operated using the procedure illustrated in FIG. 3. However, ifthe system illustrated in FIG. 2 is being used, the authorization step324 preferably comprises the procedure illustrated in FIG. 5. Up to step428, the procedure illustrated in FIG. 5 is identical to the procedureillustrated in FIG. 4, which is discussed in detail above. The furthersteps of the procedure illustrated in FIG. 5 are described as follows.

Upon receiving the data 166 comprising or derived from theauthentication response message 164, the merchant processor 104 sends afirst authorization request message 176 to the payment organizationprocessor 112 through network portion 132 (step 502). The firstauthorization request message 176 includes the authentication data inthe authentication response message, and/or data derived from theauthentication data. For example, the first authorization requestmessage 176 preferably includes an AAV or a MAC extracted from the AAV,as is discussed above with respect to the procedure illustrated in FIG.4. The payment organization processor 112 sends a second authorizationrequest message 180 to the issuer processor 108 through a network ornetwork portion 134 (step 504). The second authorization request message180 is equal to or derived from the first authorization request message176 and preferably includes the MAC. The issuer processor 108 verifiesthe second authorization request message 180—typically by verifying theAAV or the MAC as is discussed above with respect to FIGS. 6 and 7—togenerate a first authorization response message 182 (step 434), which issent from the issuer processor 108 to the payment organization processor112 through network/network portion 134 (step 506). The firstauthorization response message 182 indicates whether the verification(step 434) was successful. The payment organization processor 112 sendsto the merchant processor 104 a second authorization response message178 which is identical to or derived from the first authorizationresponse message 182 (step 508). Depending upon the result of theverification (see step 326 illustrated in FIG. 3), the transaction iscompleted (steps 332 and 334) or terminated (steps 328 and 330), as isdiscussed above with respect to FIG. 3.

Optionally, the payment organization processor 112 can perform theverification procedure 434 on behalf of the issuer processor 108, as isdiscussed above with respect to the system illustrated in FIG. 1. Ifsuch stand-in processing is performed by the payment organizationprocessor 112, then the payment organization processor 112 verifiesauthorization request message 176 to generate authorization responsemessage 178.

Preferably, the account holder registers with the issuer before beingallowed to conduct AAV-based transactions.

The registration process provides the following beneficial features:

-   -   Strong authentication of the account holder    -   Account holder registration with the issuer

To register with the issuer, the account holder first accesses theissuer's online banking Web site which is accessible from the issuer'sWeb server. Optionally, this server can be the issuer processor 108. Ifthe account holder has already registered for access to the issuer'sonline banking site, the account holder logs in using his/her existingaccess credentials. These credentials are verified using anyconventional online banking account holder authentication method.

If the account holder has not yet registered for access to the issuer'sonline banking site, the issuer's Web server—e.g., the issuer processor108—requires the account holder to register. Preferably, the serverstrongly authenticates the identity of the account holder before and/orduring registration, in order to ensure the security of subsequenttransactions performed using the payment account. Once the accountholder has been successfully authenticated, the registration processproceeds with account holder profile initialization. The account holderis presented with an option to continue registering. Selection of thecontinued registration option navigates the account holder's Web browserto a registration page. This page presents the account holder with alist of accounts that can be registered, and requests certaininformation from the account holder in order to set up the accountholder's profile within the issuer processor 108. The informationpreferably includes at least the following:

-   -   Account Number    -   Account Expiration Date    -   Account CVC2 Verification Value

The following additional information can also be collected duringprofile initialization:

-   -   Account Holder Name    -   Account Holder Billing Address    -   Account Holder Shipping Address

Optionally, the issuer can automate the profile set-up based on accountholder information which is available from the issuer's online bankingsite. Automating some or all of the set-up process makes it unnecessaryfor the account holder to re-enter this information, thus providing theaccount holder with a more convenient registration experience.

The data collected from the account holder or from the automatedinterface are stored in the issuer processor 108 as part of the accountholder's registration request. For systems in which the processorperforming the verifications is operated by an organization other thanthe issuer, the request and its resulting response should be adequatelyprotected during transmission between organizations. For example, thesecurity of the request and response can be ensured by sending thesemessages over a protected, private network connection, or by encryptingthe message prior to transmission over a public network such as theInternet. The issuer's server processes the registration request andresponds with either: (a) a confirmation that the registration wascompleted successfully; or (b) an indication that the registrationfailed, along with a message explaining the reason for the failure.

Issuers should select a strong authentication mechanism that will ensurethat the account holder being registered can be properly identified andvalidated. In particular, when issuers implement the registrationprocess, they should keep the following guidelines/preferences in mindwhen identifying shared secrets that can be used for authenticationpurposes:

-   -   Multiple pieces of information, rather than just one piece,        should be used for the shared secret. For example, the account        holder's mother's maiden name and the last four digits of        his/her social security number can be used in combination with        an issuer-generated password.    -   The shared secret should be verifiable. For example, if the        account holder's mother's maiden name is to be used, the        authorization system should be able to verify this information.    -   It should be difficult or impossible to discover the entire        shared secret without access to multiple sources. It is        preferable to avoid using a shared secret that is available        completely within one document and/or from public information.        For example, should the issuer choose to use credit line and        address information, both pieces of this shared secret are        available on the account holder's monthly account statement. If        the statement is intercepted, then the shared secret will be        compromised.    -   The issuer can optionally use several pieces of information to        determine the shared secret. For example, the following        information can be used:        -   A bank-generated password sent to the billing address of the            account holder in a mailer which is separate from the            statement.        -   A CVC2 which is only available on the signature panel of            card.        -   A verifiable non-public number such as the last four digits            of the account holder's social security number.        -   The Credit Line on the account (available on the monthly            account statement).

The account holder's access credentials—which are used to authenticatethe account holder's identity during purchase transactions—are typicallystored and managed by the issuer processor 108 and preferably includesome or all of the following:

-   -   UserID/password    -   Smart card/PIN    -   Password released wallet secret    -   Biometric verification    -   Digital certificate(s)    -   Any other secure, issuer-approved authentication mechanism

In order to maximize cardholder security and provide strong cardholderauthentication, the issuer processor 108 preferably authenticates eachtransaction.

Optionally, the issuer processor 108 can store data that tracks AAVgeneration and account holder transactions. Tracking the history of AAVgeneration, including the Card City, the Card State/Country, the Brand,and the AAV itself, can be of assistance to the issuer in supportingdispute management and chargeback processes. In addition, the issuer canchallenge account holder repudiation based on its records ofauthentication events and account holder confirmations of transactions.Such a challenge is typically based on the AAV, Card City, CardState/Country and Brand associated with each transaction. The issuer canalso choose to make the history of transactions available online to theaccount holder, thereby reducing the number of customer serviceinquires.

In the case of a purchase involving a split shipment, the merchantprocessor 104 preferably requests and obtains authorization for eachpart of the shipment. When processing a subsequent authorization due toa split shipment, the merchant processor 104 modifies the Control Byte804 contained on the initial authorization AAV 802 from hexadecimal “82”to hexadecimal “02.” Failure to modify the Control Byte 804 for asubsequent authorization will result in a decline of authorization bythe issuer processor 108.

Optionally, the merchant processor 104 can re-transmit an authorizationrequest after an initial issuer decline. If so, the AAV 802 istransmitted as a subsequent authorization with the Control Byte 804modified from hexadecimal “82” to hexadecimal “02.”

In some cases, the merchant processor 104 may generate, for a giventransaction, a second authorization request having an AAV with the samevalue as the AAV in the original request. The second authorizationrequest may not be bit-wise identical to the original request. Forexample, the requests might have different system-trace ID numbers. Themerchant processor 104 would typically generate a second authorizationrequest if:

-   -   The merchant processor 104 does not receive a response to the        original authorization request within a pre-determined time-out        period; or    -   The merchant fully reverses the original authorization, but        later decides to re-instate it.

The merchant processor 104 preferably treats such authorization requestsas subsequent authorization requests by flipping the most significantbit of the control byte 804. This will prevent such requests from beingerroneously rejected by the issuer processor 108 as possible replayattacks.

It will be appreciated by those skilled in the art that the methods andsystems illustrated in FIGS. 1-8 can be implemented on various standardcomputer platforms operating under the control of suitable softwaredefined by FIGS. 1-8. In some cases, dedicated computer hardware, suchas a peripheral card in a conventional personal computer, can enhancethe operational efficiency of the above methods.

FIGS. 9 and 10 illustrate typical computer hardware suitable forpracticing the present invention. Referring to FIG. 9, the computersystem includes a processing section 910, a display 920, a keyboard 930,and a communications peripheral device 940 such as a modem. The systemcan also include a printer 960. The computer system typically includesone or more disk drives 970 which can read and write tocomputer-readable media such as magnetic media (i.e., diskettes) and/oroptical media (e.g., CD-ROMS or DVDs), for storing data and applicationsoftware. The system also typically includes an internalcomputer-readable medium 980 such as a hard disk drive. Other inputdevices, such as a digital pointer 990 (e.g., a “mouse”) and a cardreader 950 for reading a payment card 900 can also be included. Computerhardware such as is illustrated in FIGS. 9 and 10 can be used to run thesoftware illustrated in FIGS. 3-7, and/or can be used to perform thefunctions of the user processor 102, the merchant processor 104, theacquirer processor 106, the payment organization processor 112, theauthentication processor 114, the registration database processor 110,and/or the issuer processor 108.

FIG. 10 is a functional block diagram which further illustrates theprocessing section 910. The processing section 910 generally includes aprocessing unit 1010, control logic 1020 and a memory unit 1050.Preferably, the processing section 910 can also include a timer 1030 andinput/output ports 1040. The processing section 910 can also include aco-processor 1060, depending on the microprocessor used in theprocessing unit. Control logic 1020 provides, in conjunction withprocessing unit 1010, the control necessary to handle communicationsbetween memory unit 1050 and input/output ports 1040. Timer 1030provides a timing reference signal for processing unit 1010 and controllogic 1020. Co-processor 1060 provides an enhanced ability to performcomplex computations in real time, such as those required bycryptographic algorithms.

Memory unit 1050 can include different types of memory, such as volatileand non-volatile memory and read-only and programmable memory. Forexample, as shown in FIG. 10, memory unit 1050 can include read-onlymemory (ROM) 1052, electrically erasable programmable read-only memory(EEPROM) 1054, and random-access memory (RAM) 1056. Different computerprocessors, memory configurations, data structures and the like can beused to practice the present invention, and the invention is not limitedto a specific platform. For example, although the processing section 910is illustrated in FIGS. 9 and 10 as part of a computer system, theprocessing section 910 and/or its components can be incorporated into aPDA or a mobile telephone.

Although the present invention has been described in connection withspecific exemplary embodiments, it should be understood that variouschanges, substitutions, and alterations apparent to those skilled in theart can be made to the disclosed embodiments without departing from thespirit and scope of the invention as set forth in the appended claims.

1. A method for conducting a payment transaction using payment accountidentification data associated with a payment account, the methodcomprising: a. sending an authentication request message from a userprocessor to an authentication processor, the authentication requestmessage comprising at least one of a user name, a password, transactiondata, and the payment account identification data; b. authenticating theauthentication request message by the authentication processor; and c.if the authenticating step is successful, performing a first set ofsteps, the first set of steps comprising the following steps: i. sendingan authentication response message from the authentication processor tothe user processor, the authentication response message comprisingauthentication data, ii. sending from the user processor to a merchantprocessor at least one of the authentication response message and dataderived from the authentication response message, and iii. sending afirst authorization request message from the merchant processor to atleast one of an acquirer processor and a payment organization processor,the first authorization request message comprising at least one of theauthentication data and first data derived from the authentication data.2. A method according to claim 1, further comprising: sending thepayment account identification data from the user processor to themerchant processor; sending an account holder participation requestmessage from the merchant processor to a registration databaseprocessor, the registration database processor having access to aregistration database, the account holder participation request messagecomprising at least one of the payment account identification data anddata derived from the payment account identification data; processingthe account holder participation request message by the registrationdatabase processor to determine whether the payment account is listed inthe registration database; and if the payment account is listed in theregistration database, performing a second set of steps, the second setof steps comprising the following steps: sending an account holderparticipation response message from the registration database processorto the merchant processor, the account holder participation responsemessage comprising first resource locator data, the first resourcelocator data indicating a network location of credential collectiondata, the credential collection data being accessible through a network,sending second resource locator data from the merchant processor to theuser processor, the second resource locator data comprising at least oneof the first resource locator data and data derived from the firstresource locator data, and using the second resource locator data by theuser processor to access the credential collection data through thenetwork, wherein the user processor uses the credential collection datato send the authentication request message to the authenticationprocessor in the step of sending the authentication request message. 3.A method according to claim 1, wherein the at least one of the acquirerprocessor and the payment organization processor comprises the acquirerprocessor, the first set of steps further comprising: iv. sending asecond authorization request message from the acquirer processor to anissuer processor, the second authorization request message comprising atleast one of the authentication data and second data derived from theauthentication data; v. verifying at least a portion of the secondauthorization request message by the issuer processor to generate afirst authorization response message, the first authorization responsemessage indicating whether the verifying step was successful; vi.sending the first authorization response message from the issuerprocessor to the acquirer processor; and vii. sending a secondauthorization response message from the acquirer processor to themerchant processor, the second authorization response message comprisingat least one of the first authorization response message and dataderived from the first authorization response message, the secondauthorization response message indicating whether the verifying step wassuccessful.
 4. A method according to claim 3, wherein the first set ofsteps further comprises the following step: viii. if the secondauthorization response message indicates that the verifying step wassuccessful, providing to a customer at least one of a good and aservice.
 5. A method according to claim 1, wherein the at least one ofthe acquirer processor and the payment organization processor comprisesthe payment organization processor, the first set of steps furthercomprising: iv. verifying at least a portion of the first authorizationrequest message by at least one of the payment organization processorand an issuer processor to generate an authorization response message,the authorization response message indicating whether the verifying stepwas successful; and v. sending the authorization response message fromthe payment organization processor to the merchant processor.
 6. Amethod according to claim 5, wherein the first set of steps furthercomprises the following step: vi. if the authorization response messageindicates that the verifying step was successful, providing to acustomer at least one of a good and a service.
 7. A system forconducting a payment transaction using payment account identificationdata associated with a payment account, the system comprising aprocessing arrangement configured to perform the steps of: a. sending anauthentication request message from a user processor to anauthentication processor, the authentication request message comprisingat least one of a user name, a password, transaction data, and thepayment account identification data; b. authenticating theauthentication request message by the authentication processor; and c.if the authenticating step is successful, performing a first set ofsteps, the first set of steps comprising the following steps: i. sendingan authentication response message from the authentication processor tothe user processor, the authentication response message comprisingauthentication data, ii. sending from the user processor to a merchantprocessor at least one of the authentication response message and dataderived from the authentication response message, and iii. sending afirst authorization request message from the merchant processor to atleast one of an acquirer processor and a payment organization processor,the first authorization request message comprising at least one of theauthentication data and first data derived from the authentication data.8. A system according to claim 7, wherein the processing arrangement isfurther configured to perform the steps of: sending the payment accountidentification data from the user processor to the merchant processor;sending an account holder participation request message from themerchant processor to a registration database processor, theregistration database processor having access to a registrationdatabase, the account holder participation request message comprising atleast one of the payment account identification data and data derivedfrom the payment account identification data; processing the accountholder participation request message by the registration databaseprocessor to determine whether the payment account is listed in theregistration database; and if the payment account is listed in theregistration database, performing a second set of steps, the second setof steps comprising the following steps: sending an account holderparticipation response message from the registration database processorto the merchant processor, the account holder participation responsemessage comprising first resource locator data, the first resourcelocator data indicating a network location of credential collectiondata, the credential collection data being accessible through a network,sending second resource locator data from the merchant processor to theuser processor, the second resource locator data comprising at least oneof the first resource locator data and data derived from the firstresource locator data, and using the second resource locator data by theuser processor to access the credential collection data through thenetwork, wherein the user processor is configured to use the credentialcollection data to send the authentication request message to theauthentication processor in the step of sending the authenticationrequest message.
 9. A system according to claim 7, wherein the at leastone of the acquirer processor and the payment organization processorcomprises the acquirer processor, the first set of steps furthercomprising: iv. sending a second authorization request message from theacquirer processor to an issuer processor, the second authorizationrequest message comprising at least one of the authentication data andsecond data derived from the authentication data; v. verifying at leasta portion of the second authorization request message by the issuerprocessor to generate a first authorization response message, the firstauthorization response message indicating whether the verifying step wassuccessful; vi. sending the first authorization response message fromthe issuer processor to the acquirer processor; and vii. sending asecond authorization response message from the acquirer processor to themerchant processor, the second authorization response message comprisingat least one of the first authorization response message and dataderived from the first authorization response message, the secondauthorization response message indicating whether the verifying step wassuccessful.
 10. A system according to claim 9, wherein the first set ofsteps further comprises the following step: viii. if the secondauthorization response message indicates that the verifying step wassuccessful, providing to a customer at least one of a good and aservice.
 11. A system according to claim 7, wherein the at least one ofthe acquirer processor and the payment organization processor comprisesthe payment organization processor, the first set of steps furthercomprising: iv. verifying at least a portion of the first authorizationrequest message by at least one of the payment organization processorand an issuer processor to generate an authorization response message,the authorization response message indicating whether the verifying stepwas successful; and v. sending the authorization response message fromthe payment organization processor to the merchant processor.
 12. Asystem according to claim 11, wherein the first set of steps furthercomprises the following step: vi. if the authorization response messageindicates that the verifying step was successful, providing to acustomer at least one of a good and a service.
 13. A computer-readablemedium for conducting a payment transaction using payment accountidentification data associated with a payment account, thecomputer-readable medium having a set of instructions operable to directat least one processor to perform the steps of: a. sending anauthentication request message from a user processor to anauthentication processor, the authentication request message comprisingat least one of a user name, a password, transaction data, and thepayment account identification data; b. authenticating theauthentication request message by the authentication processor; and c.if the authenticating step is successful, performing a first set ofsteps, the first set of steps comprising the following steps: i. sendingan authentication response message from the authentication processor tothe user processor, the authentication response message comprisingauthentication data, ii. sending from the user processor to a merchantprocessor at least one of the authentication response message and dataderived from the authentication response message, and iii. sending afirst authorization request message from the merchant processor to atleast one of an acquirer processor and a payment organization processor,the first authorization request message comprising at least one of theauthentication data and first data derived from the authentication data.14. A computer-readable medium according to claim 13, wherein the set ofinstructions is further operable to direct the at least one processor toperform the steps of: sending the payment account identification datafrom the user processor to the merchant processor; sending an accountholder participation request message from the merchant processor to aregistration database processor, the registration database processorhaving access to a registration database, the account holderparticipation request message comprising at least one of the paymentaccount identification data and data derived from the payment accountidentification data; processing the account holder participation requestmessage by the registration database processor to determine whether thepayment account is listed in the registration database; and if thepayment account is listed in the registration database, performing asecond set of steps, the second set of steps comprising the followingsteps: sending an account holder participation response message from theregistration database processor to the merchant processor, the accountholder participation response message comprising first resource locatordata, the first resource locator data indicating a network location ofcredential collection data, the credential collection data beingaccessible through a network, sending second resource locator data fromthe merchant processor to the user processor, the second resourcelocator data comprising at least one of the first resource locator dataand data derived from the first resource locator data, and using thesecond resource locator data by the user processor to access thecredential collection data through the network, wherein the userprocessor uses the credential collection data to send the authenticationrequest message to the authentication processor in the step of sendingthe authentication message.
 15. A computer-readable medium according toclaim 13, wherein the at least one of the acquirer processor and thepayment organization processor comprises the acquirer processor, thefirst set of steps further comprising: iv. sending a secondauthorization request message from the acquirer processor to an issuerprocessor, the second authorization request message comprising at leastone of the authentication data and second data derived from theauthentication data; v. verifying at least a portion of the secondauthorization request message by the issuer processor to generate afirst authorization response message, the first authorization responsemessage indicating whether the verifying step was successful; vi.sending the first authorization response message from the issuerprocessor to the acquirer processor; and vii. sending a secondauthorization response message from the acquirer processor to themerchant processor, the second authorization response message comprisingat least one of the first authorization response message and dataderived from the first authorization response message, the secondauthorization response message indicating whether the verifying step wassuccessful.
 16. A computer-readable medium according to claim 15,wherein the first set of steps further comprises the following step:viii. if the second authorization response message indicates that theverifying step was successful, providing to a customer at least one of agood and a service.
 17. A computer-readable medium according to claim13, wherein the at least one of the acquirer processor and the paymentorganization processor comprises the payment organization processor, thefirst set of steps further comprising: iv. verifying at least a portionof the first authorization request message by at least one of thepayment organization processor and an issuer processor to generate anauthorization response message, the authorization response messageindicating whether the verifying step was successful; and v. sending theauthorization response message from the payment organization processorto the merchant processor.
 18. A computer-readable medium according toclaim 17, wherein the first set of steps further comprises the followingstep: vi. if the authorization response message indicates that theverifying step was successful, providing to a customer at least one of agood and a service.